A communication network typically employs numerous network elements (NEs) for exchanging data across the network for delivery to a final destination. For example, within a Synchronous Optical Network (SONET), long-haul transport, ADMs, digital cross-connect systems, and other NEs communicate data to and from end-user buildings (EUBs) and other networks. SONET standards do not precisely define every aspect of the communications protocol, thereby allowing for different vendor NEs with different operational specifications. Also, a SONET network typically supports large numbers (e.g., thousands to millions) of communication sessions simultaneously. Thus, SONETs typically include numerous types of NEs from many different vendors interconnected with each other in very complex configurations. In addition, changes are frequently made to the NE configurations and interconnections. Consequently, maintaining an accurate record of these complicated configurations and interconnections at any point in time is a significant challenge.
To attempt to keep track of the NE and circuit configurations, some network providers use provisioning databases that store data representing the configuration of NEs and circuits in the network. A significant problem that has been identified relates to inaccurate representation of the actual network configuration in the provisioning database. Generally this problem arises when changes to the network are not updated in the provisioning database. Exemplary changes are a change in the model of an NE, or a change to port connections between NEs.
While most network changes are properly provisioned, some are erroneously provisioned. For example, a Fujitsu ADM may be replaced with a newer model, with connections to the ports of existing NEs being correctly provisioned. However, loopback conditions that are made for testing purposes are often not deprovisioned after the test. As another example, technicians may simply make mistakes, such as connecting the wrong ports between NEs. Regardless of whether such changes are made properly or in error, changes in NE configuration are very common (e.g., occurring throughout a network everyday), and often occur in an uncontrolled and/or undocumented manner.
Due to the complexity of NE configurations, the large number of interconnections, and the frequency of change, the current state of NE configuration can be extremely difficult to identify if the provisioning database is not updated when changes are made; and if errors are made during provisioning, the current state is not easily discernible even if the provisioning database is updated. Once connections are made between NEs, manually identifying them can be a painstaking, and time-consuming task because of the vast number of connections between NEs. Unfortunately, as indicated above, the provisioning database is frequently not updated, and provisioning errors are made. Consequently the provisioning database typically does not accurately reflect the actual network configuration.
If the provisioning database does not accurately reflect the actual NE configuration of the network, this can pose significant problems for the network provider. For example, if equipment fails on the network, the database will not provide accurate information to enable network administrators to quickly identify the source of the problem, and fixing the problem may take much longer than necessary. In addition, customers may be billed incorrectly because of incorrect assumptions about the network configuration. Furthermore, network capacity may be wasted, particularly in situations when loopback conditions are erroneously left on the network. In addition, provisioning errors may not be known until a fault condition occurs.